Security-related programming interface

ABSTRACT

A programming interface includes a first group of functions related to communicating a new security policy to multiple security engines. Each of the multiple security engines is configured to replace an existing security policy with the new security policy. The programming interface also includes a second group of functions related to communicating an indication of each security engine&#39;s readiness to implement the new security policy.

TECHNICAL FIELD

The systems and methods described herein relate to computing systemsand, more particularly, to an interface associated with processingevents, such as security-related events, and other information.

BACKGROUND

Computer systems are continuing to grow in popularity and are frequentlyinterconnected with other computer systems via networks, such as localarea networks (LANs) and the Internet. Features such as electronic mail(email), instant messaging, and online entertainment encourage the useof computer systems coupled to networks. These features allow users to,for example, communicate with other users, retrieve audio and/or videocontent, and purchase products or services via online sources.

This increased interconnection of computer systems increases thelikelihood of attacks against the computer systems by malicious users.These attacks may include installing a malicious program onto otherusers' computers (e.g., intended to disable the other users' computers,to obtain information from the other users' computers, launch attacksagainst other computers, and the like). Attacks may also includeattempting to disable a computer such that its performance is greatlyimpaired (e.g., by generating a continuous stream of requests sent tothe computer). These attacks can be a nuisance to the computer user andmay result in lost data, corrupted data, confidential data being copiedfrom the computer, or rendering the computer inoperable.

To prevent or minimize the severity of such attacks, various securityprograms and services have been developed. These programs and servicesexecute on the computer system and protect the computer system frommalicious attacks. Example programs include antivirus programs andfirewall programs. Typically, these programs or services are directedtoward preventing a particular type of attack. For example, an antivirusprogram protects against the loading and/or execution of computerviruses, and a firewall program protects against unauthorized access tothe computer by an outside user.

These different programs do not typically communicate with one another.For example, an antivirus program does not typically communicate thefact that a virus was detected to the firewall program. Thus, thevarious security programs in a computer system may not learn of certainattacks on the computer system. It would be desirable to provide aninterface that permits the communication of security policies and eventinformation among various components and security programs in a computersystem.

SUMMARY

The systems and methods described herein provide an interface associatedwith processing events and other information to enhance the security ofa computing system. In a particular embodiment, a programming interfaceincludes a first group of functions related to communicating a newsecurity policy to multiple security engines. Each of the multiplesecurity engines is capable of replacing an existing security policywith the new security policy. The programming interface also includes asecond group of functions related to communicating an indication of eachsecurity engine's readiness to implement the new security policy.

BRIEF DESCRIPTION OF THE DRAWINGS

Similar reference numbers are used throughout the figures to referencelike components and/or features.

FIG. 1 illustrates an example environment in which various events aregenerated and processed.

FIG. 2 illustrates an example security policy containing data and rules.

FIG. 3 illustrates an example table maintained by a security moduleregarding data requested by various security engines.

FIG. 4 is a flow diagram illustrating an embodiment of a procedure forretrieving and distributing security policy rules and data.

FIG. 5 is a flow diagram illustrating an embodiment of a procedure forhandling updated security policy data.

FIG. 6 is a flow diagram illustrating an embodiment of a procedure forhandling the distribution of information to one or more securityengines.

FIG. 7 is a flow diagram illustrating an embodiment of a procedure forupdating a security policy.

FIG. 8 is a flow diagram illustrating another embodiment of a procedurefor updating a security policy.

FIG. 9 illustrates a general computer environment.

FIGS. 10-21 illustrate various example implementations of a programminginterface.

DETAILED DESCRIPTION

The systems and methods discussed herein process various information,such as events generated by one or more programs or services. Further,an interface is described that permits the communication of information,such as security-related information, among various components andprograms in a computing system. The computing system includes an eventmanager that receives events and other information from multiplesources, such as security engines and other computing systems. Examplesecurity engines include antivirus engines, firewall engines andintrusion detection engines. The event manager communicates eventinformation received from a particular source to one or more securityengines that might use the information to improve the level of securityprovided for the computing system.

Although particular examples discussed herein refer to security-relatedevents and other security-related information, alternate embodiments mayprocess any type of event or information. This information includes anyinformation that might be utilized by security-related components in ahost computer. Alternate embodiments can receive, process and distributeinformation that is not necessarily related to the security of the hostcomputer. The terms “interface”, “program interface” and “applicationprogram interface (API)” are used interchangeably herein.

Event Processing

FIG. 1 illustrates an example environment 100 in which various eventsare generated and processed. Events include, for example, detection of acomputer virus, detection of an attempt to access confidential data,notification that a computer virus was destroyed, notification that aparticular application program was halted or prevented from executing,changes to system state information, and so forth. A host computer 102is coupled to multiple servers 104 and 106 via a network 108. Hostcomputer 102 and servers 104 and 106 may be any type of computingdevice, such as the device discussed below with respect to FIG. 9.Network 108 can be any type of data communication network, such as alocal area network (LAN), wide area network (WAN); the Internet, and thelike. Although FIG. 1 show host computer 102 coupled to two servers 104and 106, host computer 102 may be coupled to any number of servers orother devices capable of communicating with the host computer.

Environment 100 can represent any of a variety of a settings, such asnetworks in home, business, educational, research, etc. settings. Forexample, server 104 may be a server device on a corporate LAN, and hostcomputer 102 may be a desktop or portable computing device on thecorporate LAN. By way of another example, server 104 may be a serverdevice on the Internet, and host computer 102 may be a desktop computingdevice at a user's home.

Host computer 102 includes a security module 110 that performs varioussecurity-related functions, such as monitoring, detecting and respondingto attacks on host computer 102. Security module 110 includes an eventmanager 112 that is coupled to three security engines 114, 116 and 118.A security engine can be any service that assists in protecting againstmalicious users and/or malicious programs. Security engines 114-118 maybe implemented in hardware or a combination of software and hardware.Particular security engines are security-related application programs,such as antivirus programs and intrusion detection programs. Securityengines 114- 118 may also be referred to as “services”. A particularsecurity module 110 may include any number of security engines coupledto event manager 112. Security module 110 may also include othermodules, components, or application programs (not shown), such as asecurity-related policy reader or other policy-handling mechanism.

Security module 110 is also coupled to system state information 120 andsystem configuration information 122. System state information 120includes information regarding the current operating state or operatingmode of host computer 102. System configuration information 122 includesinformation regarding how host computer 102 is configured. System stateinformation 120 and system configuration information 122 may be storedin a non-volatile storage device, such as a memory device or a hard diskdrive. In one embodiment, event manager 112 and security engines 114-118are capable of receiving system state information 120 and systemconfiguration information 122.

Host computer 102 also includes an application program interface (API)124 that permits the communication of security policies and eventinformation among various components and programs in host computer 102or other devices. For example, API 124 allows components or programs tocommunicate with security engines 114-118 or event manager 112 to sendor receive security-related information. API 124 also facilitates, forexample, loading new security engines, unloading existing securityengines, sending security policies to security engines, communicatingchanges in data to security engines, user interaction with securityengines, and centralized configuration management of security engines.Additional details regarding API 124 are discussed below.

Although not shown in FIG. 1, additional data sources or data providersmay communicate information and events to security module 110 and eventmanager 112. This additional data includes, for example, configurationinformation related to an Internet Information Service (IIS), dataprovided by an system management application, data contained in a systemregistry, and information provided by a user or administrator of thesystem.

Each security engine 114-118 performs certain security-related functionsto help secure host computer 102 from malicious users or applicationprograms. These malicious users or application programs may attempt todisable host computer 102 or disable functionality of host computer 102,obtain data from host computer 102 (such as passwords or otherconfidential information), or use host computer 102 (such as to assistin attacking other computer systems). For example, security engine 114detects computer viruses, security engine 116 provides firewallprotection, and security engine 118 blocks execution of particularapplication programs based on one or more user privileges orcharacteristics. In this example, security engine 114 protects hostcomputer 102 from being infected by computer viruses, worms, Trojanhorses, and the like. Additionally, firewall protection includesprotecting host computer 102 from being accessed over a networkconnection by other devices. Blocking execution of particularapplication programs includes preventing execution of applicationprograms on host computer 102 by a user that does not have appropriateprivileges. Additionally, execution of an application program may beblocked if improper behavior is detected, such as improper networkaccess or improper storage device access.

In other embodiments, one or more security engines may perform intrusiondetection or vulnerability analysis. Intrusion detection includes, forexample, identifying when a malicious application program and/or userhas accessed host computer 102 and taking appropriate action to notify auser or administrator, attempt to disable the malicious applicationprogram, or halt the malicious user's access. Vulnerability analysisincludes, for example, attempting to detect vulnerabilities in hostcomputer 102 due to security engines or other components that have notbeen installed or updated correctly, security engines or othercomponents that have not been configured properly, patches or hot fixesthat have not been installed, passwords that do not comply with requiredlengths or required characters, and the like. A particular securityengine 114-118 may be unaware of the existence and functionality ofother security engines coupled to event manager 112.

Each security engine 114-118 communicates events (e.g., detection of acomputer virus, detection of an attempt to retrieve data from hostcomputer 102, or preventing execution of an application program by auser) to event manager 112. These events include information collectedby a security engine, actions taken by a security engine, data collectedby the event manager from one or more data sources, and the like.Example information includes a listing of all virtual serversinstantiated in a particular installation. Event manager 112 processesthese events and communicates the information contained in particularevents to other security engines 114-118 that may benefit from suchinformation.

Security module 110 also receives security-related policies that includeone or more rules and various data. Event manager 112 distributes therules to the appropriate security engines 114-118 and provides data tothe security engines, as needed. Each security engine 114-118 storesthese rules and data received from event manager 112. The operation ofsecurity module 110, event manager 112 and security engines 114-118 isdiscussed in greater detail below.

FIG. 2 illustrates an example security policy 200 containing data andrules. In one embodiment, security policy 200 is stored in securitymodule 110. A particular security module may receive and store anynumber of different security policies 200 received from any number ofdifferent data sources. Alternatively, security policy 200 may be storedin another module or component within host computer 102. In the exampleof FIG. 2, a data portion 202 of security policy 200 includes one ormore data elements. As shown in FIG. 2, these data elements includevalues assigned to variables (e.g., a value of “1” is assigned tovariable “A” and a value of “4” is assigned to variable “B”). Inalternate embodiments, other types of data may be included instead of orin addition to the data shown in FIG. 2. The data contained in securitypolicy 200 is used, for example, by one or more rules contained insecurity policy 200 or contained in one or more other security policies.

Security policy 200 also includes a rules portion 204 that containsmultiple rules. The rules in security policy 200 may be associated withone or more security engines. For example, certain rules may only beapplied by particular security engines. The rules may be arranged insecurity policy 200 based on the security engine with which the rulesare associated. Alternatively, an identifier associated with each rulemay identify the security engines that are capable of applying the rule.In particular embodiments, a rule may be associated with any number ofsecurity engines. In other embodiments, a host computer may not containa security engine that applies a particular rule. In this situation, therule is not associated with any security engine.

In the example of FIG. 2, the rules are defined using an IF-THENstructure. Alternatively, the set of rules can take a variety ofdifferent forms. Using the IF-THEN structure shown in FIG. 2, the ruledefines a particular condition(s) and a corresponding particularaction(s) or result(s). During enforcement of the rule, if thatparticular condition(s) is detected, then the corresponding particularaction(s) or result(s) is performed. A rule can identify a variety ofdifferent conditions and corresponding actions or results. Exampleconditions include attempts to access a resource (e.g., memorylocations, network addresses or ports, other programs, or files on astorage device), attempts to write data to particular locations (e.g.,particular memory locations, or particular locations on a storagedevice), attempts to run particular programs, and various aspects of thecurrent operating state of host computer 102. Example results includepreventing a resource from being accessed, preventing data from beingwritten to particular locations, preventing a program from beingexecuted, or generating a notification that the occurrence of thecondition in the rule was detected (e.g., recording its occurrence in alog, or sending a message to a user or other computer). The particularresults can also be permissive in nature rather than preventive. Forexample, the results could indicate that a particular resource orlocation can be accessed only if the condition in the rule is satisfiedby host computer 102, or that a particular program can only be run ifthe condition in the rule is satisfied by host computer 102.

Additional examples of rules include permitting certain applicationprograms or services to update data files in a particular directory orfolder, enabling receipt of traffic on port 21 if file transfer protocol(FTP) is enabled, and generating a virus warning message if a particularvirus signature is detected. Other examples include generating an eventif a particular application program has not been upgraded to aparticular revision level, preventing access to a network if theapplication program has not been upgraded to a minimum revision level,and preventing the host computer from receiving data via network port35.

FIG. 3 illustrates an example table 300 maintained by a security moduleregarding data requested by various security engines. In one embodiment,table 300 is stored in security module 110. Alternatively, table 300 maybe stored in another module or component within host computer 102. Eachtime a security engine requests data from the security module, thesecurity module updates the table (if necessary) to include that datarequest. A first column 302 of table 300 identifies a particular dataelement, such as a variable or other identifier or information. A secondcolumn 304 of table 300 identifies any security engines that previouslyrequested the associated data element. For example, table 300 identifiesthat data element “A” was previously requested by security engine “1”.Similarly, data element “D” was previously requested by security engines“1”, “4” and “6”. As discussed in greater detail below, the informationcontained in table 300 is used by the security module to determine whichsecurity engines should receive updated data.

FIG. 4 is a flow diagram illustrating an embodiment of a procedure 400for retrieving and distributing security policy rules and data.Procedure 400 may be performed, for example, upon initialization of ahost computer. Initially, a security module retrieves security policiesfor the host computer (block 402). A event manager identifies rules inthe security policies related to each security engine (block 404). Theevent manager then communicates the rules to the appropriate securityengines (block 406).

Each security engine identifies data necessary to apply its associatedrules (block 408), for example by identifying data elements contained inrules that the security engine will apply. Each security engine thenrequests its identified data from the event manager (block 410). Afterreceiving a data request from a security engine, the event managerrecords the requested data element in a table (e.g., table 300 in FIG.3) or other data structure for future reference (block 412). Finally,the event manager locates the requested data and provides that data tothe requesting security engine (block 414). Thus, rather than providingall data to all security engines, the event manager provides therequested data to each requesting security engine.

FIG. 5 is a flow diagram illustrating an embodiment of a procedure 500for handling updated security policy data. Initially, the securitymodule receives updated data (block 502). For example, the updated datamay include updated values for existing variables. The security moduleidentifies one or more security engines that previously requested thedata that has been updated (block 504). In one embodiment, the securitymodule identifies these security engines using a table such as table 300shown in FIG. 3. After identifying the appropriate security engines, thesecurity module provides the updated data to each of the identifiedsecurity engines (block 506). Finally, the security engines update theirdata elements with the updated data. Procedure 500 is repeated each timethe security module receives updated data. In another embodiment, thesecurity module periodically checks various data sources for updateddata. If the data has been updated, the security module retrieves theupdated data and distributes the data according to procedure 500.

In one embodiment, when a rule is updated, the security moduleidentifies the security engines associated with the rule and distributesthe updated rule to the identified security engines. If a new rule isreceived, the security module identifies the security engines that mightuse the new rule and distributes the new rule to the appropriatesecurity engines. Similarly, if an existing rule is deleted, thesecurity module deletes the rule from all security engines associatedwith the rule. In another embodiment, when a rule is updated, thesecurity module creates a new set of rules (including the updated rule)and distributes the new set of rules to the security engines, therebyreplacing the existing rules contained in the security engines.

FIG. 6 is a flow diagram illustrating an embodiment of a procedure 600for handling the distribution of information, such as event informationor system state information, to one or more security engines. Initially,the event manager receives an event from a security engine (block 602).The event manager then identifies information contained in the event(block 604), such as the event type or the nature of the attack thatgenerated the event. The event manager also identifies other securityengines that might use the information contained in the event (block606). The relationships among different security engines are specified,for example, in the security policy received by the host computer. Theserelationships may be defined wholly or in part by a system administratoror other system operator when creating the security policy.

Next, the event manager provides the information contained in the eventto the identified security engines (block 608). The identified securityengines then apply the received information (block 610). This sharing(or correlation) of event information enhances the level of securityprovided by a host computer against malicious attacks. Sharing of theevent information is handled by the event manager such that theindividual security engines do not need to know of the other securityengines contained in the host computer. The security-related informationdiscussed herein can be stored in a central location, thereby allowingother devices, components and application programs to access theinformation. For example, other security engines or computing systemsmay access the stored security related information.

In one example of procedure 600, an antivirus security engine detectsrepeated attempts to access a network via a particular port. Theantivirus security engine reports this information (e.g., dates andtimes of the attempted access and the port on which access wasattempted) to the event manager. In this example, the antivirus securityengine is not responsible for responding to such access attempts. Theevent manager receives the information from the antivirus securityengine and determines that an intrusion detection security engine and afirewall security engine may use such information. After receiving theinformation, the intrusion detection security engine and the firewallsecurity engine may adjust their operation based on the receivedinformation. For example, the intrusion detection security engine mayincrease the frequency with which it checks for intruders. Additionally,the firewall security engine may temporarily disable the port on whichaccess was attempted. Thus, the overall security of the host computeragainst attacks is increased by allowing security engines to adjusttheir operation based on shared information regarding security-relatedevents.

In another example of procedure 600, a vulnerability security enginedetects whether a particular patch is installed on the host computer. Ifthe patch is not installed, the vulnerability security engine generatesan event indicating that the patch is not installed. A host firewallsecurity engine and a behavioral blocking security engine haveregistered with the event manager for notification if the patch is notinstalled. When the host firewall security engine and the behavioralblocking security engine receive notification of the patch not beinginstalled, the security engines enforce rules that limit thefunctionality (or prevent execution) of the application program that wasnot patched.

In another embodiment, system state information is shared among variouscomponents (e.g., the event manager and multiple security engines) inthe security module. The system state information may be provided byvarious data sources. Example system state information includes acurrent network state, whether a network connection is wired orwireless, whether the host computer is accessing a corporate network oran unknown network, and host computer configuration information. Thus,if a security engine identifies particular system state information,that identified information can be shared among other security enginesand other components or modules in the host computer.

In a particular embodiment, the system state information collected byvarious components is stored in a central location, thereby providingaccess to the information by other devices, components and applicationprograms. For example, system state information collected by onesecurity engine is accessible by other security engines, securitymodules and computing systems.

Security Policy Updates

As discussed above, a security policy can be used to describe the rulesthat are to be applied, for example, by security engines or securityproviders. When changes are made to the security policy, updated rulesare supplied to the various security engines, and these various securityengines change over to start using the updated rules at substantiallythe same time.

In addition to the components, programs and modules discussed above withrespect to FIG. 1, host computer 102 receives security policies from oneor more source devices, such as servers 104 and 106. The securitypolicies describe how various security engines on host computer 102should operate. Although only one host computer 102 is illustrated inFIG. 1, it is to be appreciated that multiple host computers 102 canobtain security policies from the same source device.

Example source devices include desktop or workstation computing devices,server computing devices, portable or handheld computing devices, gameconsoles, network appliances, cellular phones, personal digitalassistants (PDAs), networking devices (e.g., routers, gateways,firewalls, wireless access points, etc.), and so forth.

Host computer 102 may also include a policy reader module, a rulemanager, a rule set generator module, and a dynamic rules data store. Itis to be appreciated that one or more of these modules may be combinedinto a single module, and/or one or more of these modules may beseparated into two or more modules.

Generally, to update the security policy being enforced by securityengines 114-118, the policy reader obtains a security policy from asource device. The rule set generator uses the newly obtained securitypolicy to generate, for each of the various security engines, a set ofone or more rules and associated data. These sets of rules are thencommunicated to the various security engines, and the associated data isstored in the dynamic rules data store. The associated data can also becommunicated to the security engines. Upon receiving the set of one ormore rules, each security engine processes the new set of rules, gettingready to begin using the new set of rules. However, each security enginecontinues to use its current set of rules until instructed to change tothe new set. A rule manager instructs all of the security engines tochange to the new set of rules after the rule manager receives anindication from each of the security engines that it is ready to changeto the new set of rules.

In certain embodiments, the rule manager coordinates the updating ofsecurity policies in host computer 102. The rule manager receives theindications from the various security engines that indicate the securityengines are ready to change to the new set of rules, and gives anindication to the security engines when they should begin using the newset of rules.

The policy reader module obtains a new security policy from the sourcedevice. The policy reader module may be configured to check whether anew security policy is available from the source at regular or irregularintervals, or alternatively may receive an indication from some othercomponent (e.g., the rule manager, the source device, or some otherdevice not shown in FIG. 1, that it should obtain a new security policyfrom the source (or check whether a new security policy is availablefrom the source). The policy reader may identify to the source aparticular security policy that the policy reader desires to obtain, oralternatively may merely request the most recent security policy for thehost computer from the source. A comparison between the current securitypolicy being used by the host computer and the most recent securitypolicy may be made to determine whether the most recent security policyis already being enforced on the host computer. Such a comparison couldbe made by the source, the policy reader, or alternatively by some othercomponent.

When the new security policy is obtained from the source, the rule setgenerator generates a set of rules for each of the different securityengines 114-118. Different security engines may use different rules whenenforcing the security policy on host computer 102. For example, onesecurity engine 114 may be a firewall whereas another security engine116 may be an antivirus component. The security policy may identifyrules that are specific to the antivirus engine (and thus the firewallengine need not be concerned with them), and may also identify rulesthat are specific to the firewall engine (and thus the antivirus engineneed not be concerned with them).

In certain embodiments, the security policy itself is a list of rulesand associated data. The security policy may also include an indicationof which rules and data are for which security engines, or alternativelyno such indication may be included (e.g., relying on the host computerto determine which rules are for which security engines). The securitypolicy allows designers to have a single record or file of all the rulesinvolved in the protection of the host computer, without having toseparate the rules across different records or files for the differentsecurity engines.

Additionally, using the techniques described herein, new securitypolicies can be prepared by designers that shift responsibility forprotecting against particular attacks from one security engine toanother. For example, protection against a particular type of attack maybe enforced by an antivirus program in one security policy but changedto being enforced by a firewall program in a new security policy. Usingthe techniques described herein, the designers can be confident thatthis shift in responsibility will occur in all of the security enginessubstantially concurrently, thereby reducing the vulnerability of thehost computer to attacks during the shift.

The rule set generator identifies, based on the security policy, whichrules and associated data (if any) are used by which of the securityengines. For each security engine, the rule set generator generates aset of rules for that security engine and makes that generated set ofrules available to that security engine (e.g., the set of rules may betransmitted or sent to the security engine, the security engine may beinformed of a location in memory where the generated set of rules can beobtained, etc.). This generation can be performed in a variety ofdifferent manners. For example, a new set of rules may be generated bythe rule set generator without regard for the current rules beingenforced by the security engines. By way of another example, the currentset of rules may be modified or changed to incorporate any differencesbetween the current and new set of rules. Additionally, the rule setgenerator may simply copy the rules from the security policy, oralternatively the rule set generator may generate the rules based oninformation in the security policy that describes the rules.

In certain embodiments, the security policy identifies which rules areto be distributed to which security engines. For example, each rule maybe associated with a particular label or identifier (e.g., SecurityEngine 1, or Antivirus engine, etc.). The rule set generator can usethese identifiers in generating the sets of rules for the varioussecurity engines. In alternate embodiments, the rule set generator mayinfer which rules are to be distributed to which security engines. Inother embodiments, a combination of these techniques may be used (e.g.,for some rules the security policy may identify which security enginethey are to be assigned to, and for other rules the security policygenerator may infer which security engine they are to be assigned to).

The set of rules generated by the rule set generator can take any of avariety of different forms. In certain embodiments, the rules follow anif-then structure as discussed above. Using this structure, the ruledefines a particular condition(s) and a corresponding particularaction(s) or result(s). During enforcement of the rule, if thatparticular condition(s) is detected then the corresponding particularaction(s) or result(s) is performed. Any of a variety of conditions andcorresponding results can be identified by a rule. Examples ofparticular conditions include: attempts to access particular resources(e.g., memory locations, network addresses or ports, other programs,files on a storage device, and so forth), attempts to write data toparticular locations (e.g., to particular memory locations, toparticular locations on a storage device, etc.), attempts to runparticular programs, various aspects of the current operating state ofthe host computer (e.g., resources available, programs running, etc.),and so forth. Examples of particular results include: preventing aresource from being accessed, preventing data from being written toparticular locations, preventing a program from being run, generating anotification that the occurrence of the condition in the rule wasdetected (e.g., recording its occurrence in a log, sending a message toa user or other computer, and so forth). The particular results can alsobe permissive in nature rather than preventive. For example, the resultscould indicate that a particular resource or location can be accessedonly if the condition in the rule is satisfied by the host computer, orthat a particular program can be run only if the condition in the ruleis satisfied by the host computer.

In certain embodiments, host computer 102 includes a dynamic rules datastore which is the data associated with the various rules being enforcedby the security engines. In certain embodiments, the dynamic rules datastore may include two sets of data: one set for the current rules beingenforced by the security engines, and another set for the new rules thatthe security engines are being updated to enforce. When a new securitypolicy is received, the rule set generator updates the dynamic rulesdata store with the data associated with the sets of new rules passed tothe security engines.

Each security engine includes a rule change module that receives a setof one or more rules from the rule set generator. The data associatedwith the rules may be received from the rule set generator along withthe rules, or alternatively the rule change module may obtain the datait desires from the dynamic rules data. Additionally, it should be notedthat although the rule set generator is discussed above as generating aset of rules for each security engine based on the security policy,alternatively each security engine may receive the entire securitypolicy (or most of the security policy) and generate their own set ofrules rather than receiving the set from the rule set generator.

The rule change module processes the new set of rules as needed in orderto generate new internal rules that enforce the new policy. Theprocessing of the new set of rules to generate new internal rules refersto whatever actions are necessary for the security engine to take inorder to place the new set of rules in a state that they can be enforcedby the security device. For example, this processing may includeconverting the new set of rules to an internal format, storing rules inparticular memory locations, organizing rules into a particulararrangement or order, etc. The rule change module may generate new rulesin any of a variety of manners; the rule change module may keep therules in the same format as they were received from the rule setgenerator or alternatively convert the rules to an internal format useby the security engine.

Regardless of how the new rules are generated, each security enginemaintains a current set of rules which enforce the previous securitypolicy for the host computer (the security policy which is beingupdated). While generating the new rules, and even after the new rulesare generated, the security engine continues to enforce the currentrules. The security engine does not begin enforcing the new rules untilinstructed to do so (e.g., by the rule manager).

After the rule change module has finished generating the new rules, therule change module indicates to the rule manager that it has finishedand is ready to switch to using the new rules (and thus begin enforcingthe new security policy). After the rule manager has received such anindication from all of the security engines, the rule manager instructseach of the security engines to begin using the new rules. The rulemanager waits to instruct each of the security engines to begin usingthe new rules until after the rule manager receives the indication fromall of the security engines. Once instructed to do so, each securityengine begins using the new rules. As soon as a security engine beginsusing the new rules, it can delete the rules it was previously using.

In some situations, a security engine may fail in processing the newrules. In such situations, the security engine returns an indication ofsuch failure to the rule manager. Alternatively, the rule manager mayimpose a time limit on responses from the security engines. If allsecurity engines have not responded with an indication that they areready to begin using the new rules within the time limit, the rulemanager can assume that one or more of the security engines has failedin processing the new rules.

When the rule manager identifies that one or more of the securityengines has failed in processing the new rules, the rule manager doesnot instruct any of the security engines to begin using the new rules.Rather, the rule manager sends an indication to abort the changeover tothe new rules (this may also be referred to as a rollback). Such anabort or rollback indication informs each of the security engines thatit is to ignore the new rules received from the rule set generator aswell as any new rules resulting from its processing, and continue to usethe current rules. In certain embodiments, the security engines cansafely delete the new rules they generated (or are in the process ofgenerating) in response to such an abort or rollback indication.

In certain embodiments, each security engine waits until it can nearlyensure that it can begin using the new rules before informing the rulemanager that it is ready to begin using the new rules. In other words,the security engine waits to inform the rule manager that it is ready tobegin using the new rules until the security engine is to the point inprocessing the new rules that it is virtually impossible for thesecurity engine to fail to begin enforcing those rules when instructedto do so. In certain embodiments, this is accomplished by the securityengine generating the new set of rules, and maintaining a pointer towhich of the rule sets (old rules or new rules) it is to use. After thenew set of rules is generated, the security engine indicates to the rulemanager that the security engine is ready to begin using the new set ofrules. Then, when instructed to begin using the new set of rules, thesecurity engine can simply change its pointer from the old set of rulesto the new set of rules. The security engine can nearly ensure that itcan change its pointer and begin using the new rules. It is to beappreciated that “nearly ensure” does not require a 100% guarantee thatfailure is absolutely impossible. It is possible that certain situationscould still arise that would result in failure (e.g., a power loss orvirus attack that prohibits changing of the pointer). However, it isalso to be appreciated that the chances of failure are very small.

The rule manager can instruct the security engines to begin using thenew set of rules (also referred to as switching over to the new set ofrules) in any of a variety of different manners. The manner that isused, however, should operate to inform all of the security engines atsubstantially the same time so that all of the security engines canbegin using their new sets of rules at substantially the same time (alsoreferred to herein as substantially concurrently). By having all of thesecurity engines begin using their new sets of rules at substantiallythe same time, any vulnerability of the host computer due to the rulechangeover is reduced. Generally, the closer in time that the securityengines begin using their new sets of rules, the lesser thevulnerability during the changeover to the new set of rules. Followingare some examples of ways in which the rule manager can instruct thesecurity engines at substantially the same time to begin using their newsets of rules.

One way in which the rule manager can instruct the security engines tobegin using the new set of rules is to use an event object that can befired across all of the security engines at once. For example, eachsecurity engine, upon receipt of the new rules from the rule setgenerator, sets an internal flag to start polling a particular eventeach time the rules are accessed (during its normal operation ofprotecting the host computer). The rule manager can then instruct thesecurity engines to begin using their new sets of rules by firing theevent (the same one being polled by the security engines). So, after theevent is fired, any subsequent polling of the event will reflect thatthe event has been fired and thereby inform the polling security enginethat the new rule set should be used. For example, in response todetecting the event having been fired, the pointer in the securityengine can be changed to point to the new set of rules.

In addition to polling the event, a thread may also be run by thesecurity engine that waits on the event. When the event is fired, thethread detects the firing so that the security engine is informed thatthe new rule set should be used. For example, in response to the threaddetecting that the event has fired, the pointer in the security enginecan be changed to point to the new set of rules.

Once the event has been fired and the new set of rules is being used,the security engine can stop polling the event. Additionally, if athread waiting on the event is run by the security engine, that threadcan be terminated.

Another way in which the rule manager can instruct the security enginesto begin using the new set of rules is to call a function exposed byeach of the security engines (e.g., a “switch” function). Calling such afunction of a security engine instructs that security engine to beginusing the new set of rules. For example, in response to such a functionbeing invoked on a security engine, the security engine changes itspointer to point to the new set of rules.

Another way in which the rule manager can instruct the security enginesto begin using the new set of rules is to notify each of the securityengines of a shared data structure that each security engine can access.The rule manager can inform each security engine of the shared datastructure at different times, such as by calling a function on eachsecurity engine (e.g., an “identify data structure” function), or byidentifying the shared data structure when the new rules are passed tothe security engine. The shared data structure can take any of a varietyof different forms, such as a location in memory (e.g., in random accessmemory (RAM) or a nonvolatile memory such as Flash memory), a filestored on a local or remote storage device, and so forth.

Each security engine checks this shared data structure (e.g., each timethe rules are accessed (during its normal operation of protecting thehost computer)) to determine its value. The rule manager can instructeach of the security engines to begin using the new rule set by changingthe value(s) stored in the shared data structure. For example, theshared data structure may initially store a value of “previous” or avalue of 0 to indicate that the current set of rules are to be used, andwhen it is time to switch to begin using the new rule set the rulemanager can write a value of “new” or “switch” or a value of 1 to theshared data structure to indicate that the new set of rules are to beused.

As discussed above, the dynamic rules data store stores the dataassociated with the various rules being enforced by the securityengines. As such, when the host computer is being updated to beginenforcing a new policy, the data used by the security engine may alsochange. This data can also change during the operation of the hostcomputer (e.g., a security engine may later request data from or storedata in the dynamic rules data store). In order for the proper data tobe made available to the security engines, when updating the securitypolicy the dynamic rules data store may operate in the same manner as asecurity engine. That is, two sets of rules data would be maintained—thefirst set would be used prior to the switch and the second set would beused after the switch. The new data would be stored in the dynamic rulesdata store, and the dynamic rules data store would return an indicationto the rule manager when it is ready to begin using the new set of data.The dynamic rules data store then continues to use the previous set ofdata until receiving an instruction from the rule manager to begin usingthe new set of data.

It should be noted that the various components in the host computer canbe implemented within the same application process executing on the hostcomputer. For example, the policy reader, the rule manager, the dynamicrules data, the rule set generator, and the security engines may all bepart of the same application process.

Alternatively, different components in the host computer can beimplemented across two or more application processes executing on thehost computer. For example, one or more security engines may run in aprocess that is separate from the other security engines as well asseparate from the policy reader, the rule manager, the dynamic rulesdata, and the rule set generator. Allowing different components to runin different application processes allows, for example, differentdevelopers to design different plug-in components (e.g., differentplug-in security engines) to enhance the security of the host computer.These additional plug-in components would be upgraded to enforce newpolicies in the same manner as other non-plug-in components.

When separating the components across multiple application processes, amechanism is used to allow the various components to communicate withone another. This communication allows, for example, sets of new rulesand data to be passed to security engines in different processes, datato be passed from security engines in different processes to the dynamicrules data, instructions to begin using the new sets of rules to bepassed to security engines in different processes, and so forth. By wayof example, the components discussed herein may be implemented asComponent Object Model (COM) components. Additional informationregarding the Component Object Model architecture is available fromMicrosoft Corporation of Redmond, Wash.

It should be noted that in the discussions herein, each security engineis instructed to begin using its new set of rules by the rule manager.Alternatively, this instruction may be implemented in other manners thatstill allow each security engine to begin using its new set of rulessubstantially concurrently. For example, rather than using the rulemanager, a control mechanism to instruct each security engine to beginusing its new set of rules may be distributed across the varioussecurity engines. This could be accomplished, for example, by each ofthe security engines notifying each other security engine that it isready to begin using the new set of rules, with none of the securityengines beginning to use its new set of rules until all of the securityengines have notified all of the other security engines that they areready to begin using the new set of rules.

FIG. 7 is a flowchart illustrating an example process 700 for updating asecurity policy. Process 700 is implemented by a component(s) that iscoordinating the updating of the security policy on a host computer,such as the rule manager discussed herein. Process 700 may be performedin software, hardware, firmware, or combinations thereof.

Initially, a new policy to be enforced on the device is obtained (block702). The policy may be obtained in a “pull” manner, where the hostcomputer initiates the access to the source of the new policy to checkwhether a new policy is available from the source. The policy mayalternatively be obtained in a “push” manner, where the host computer isinformed of (e.g., sent a message or other indication of) theavailability of a new security policy or of the new security policyitself.

Regardless of how the new policy is obtained, once the new policy isobtained a new set of rules and/or data associated with the rules forthe new policy is provided to each of the security devices (block 704).As discussed above, different sets of rules and/or data can be generatedbased on the new policy for each security engine.

Return values are then received from the security engines (block 706).In certain implementations, each security engine returns, to thecomponent implementing process 700, a value signifying “OK” or a valuesignifying “Fail”. When a security engine returns a value signifying“OK” it indicates that the security engine has processed the set ofrules and/or data that it received and is ready to begin using the newset of rules and/or data. This may also be referred to as a securityengine's readiness to implement the new set of rules and/or data. Forexample, all that remains is for the security engine to change itspointer to point to the new set of rules rather than the previous set ofrules. However, when a security engine returns a value signifying“Fail”, it indicates that the security engine could not (or did not)process the set of rules and/or data and that the security engine is notable to begin using the new set of rules and/or data. Additionally, asdiscussed above a time limit (also referred to as a timeout value or athreshold amount of time) may be imposed on responses from securityengines—if a security engine does not respond with a value signifying“OK” or “Fail” within this time limit the component implementing process700 treats the security engine as if it had returned a value signifying“Fail”.

It is to be appreciated that the sending of rules and the receiving ofresponses (blocks 740 and 706) is an asynchronous process. Differentsecurity engines may take different amounts of time to process the rulesand/or data they receive, and process 700 simply waits until all of thesecurity engines have finished their respective processing (up to anyoptional time limit that is imposed).

Process 700 proceeds based on whether all of the security engines havereturned a value signifying “OK” (block 708). If all of the securityengines have returned a value signifying “OK”, then all of the securityengines are ready to begin using the new set of rules, so all of thesecurity engines are instructed to begin using the new set of rulesblock 710).

However, if at least one of the security engines does not return a valuesignifying “OK”, then a rollback call is issued to each security engine(block 712). This rollback call essentially aborts the update process,so none of the security engines will begin to use the new set of rulesyet (even those security engines that had returned a value signifying“OK”).

FIG. 8 is a flowchart illustrating another example process 800 forupdating a security policy. Process 800 is implemented by a securityengine on a device, such as a security engine 114-118 on host computer102 of FIG. 1. Process 800 may be performed in software, hardware,firmware, or combinations thereof.

Initially, a new set of rules and/or data are received for the newpolicy to be enforced (block 802). As discussed above, the rules anddata may be received at substantially the same time, or alternativelythe security engine may obtain data from a data store (e.g., the dynamicrules data store discussed herein) as needed. The new rules and/or dataare then processed (block 804). Processing of the new rules and/or datacreates an internal set of rules for the security engine to follow(e.g., in an internal format of the security engine) in enforcing thenew security policy.

Process 800 proceeds based on whether the processing of the rules wassuccessful (block 806). If the security engine has finished processingthe set of rules and/or data that it received and is ready to beginusing the new set of rules and/or data (e.g., all that remains is forthe security engine to change its pointer to point to the new set ofrules rather than the previous set of rules), then the processing wassuccessful. Otherwise, the processing was not successful. If theprocessing was successful than a value signifying “OK” is returned(block 808). However, if the processing was not successful then a valuesignifying “Fail” is returned (block 810). The return values in blocks808 and 810 are returned to a component(s) that is coordinating theupdating of the security policy on the host computer (e.g., the rulemanager discussed herein).

Regardless of the value returned, the security engine continues to usethe previous or old set of rules until instructed to rollback or beginusing new rules (block 812). If instructed to begin using the new rules,then the security engine begins using the new rules and/or data (block814), such as by changing a pointer from its previous set of rules toits new set of rules. The instruction to begin using the new rules canbe received by the security engine in any of a variety of manners, asdiscussed above.

However, if instructed to rollback, then the security engine discardsany results of processing the new rules and/or data (block 816). Thisdiscarding can be performed regardless of whether the security enginehas finished processing the new set of rules it received.

Thus, as can be seen in FIG. 8, the security engine continues to use itsprevious set of rules until an indication to switch to the new rules isreceived. By the time such an indication is received, the securityengine is ready to begin using the new rules, and very little time isrequired for the switch to occur. For example, the security engine maysimply need to switch a pointer to point to its new set of rules ratherthan its previous set of rules.

Application Program Interface (API)

An API, such as API 124 discussed above with respect to FIG. 1, permitsthe communication of security policies and event information amongvarious components and programs (e.g., security engines) in the hostcomputer. In one embodiment the API is defined using the ComponentObject Model (COM). The API supports methods for loading and unloadingsecurity engines, sending security policies to security engines,communicating changes in security policy data to interested securityengines, allowing the host user to interact with the security engine atdecision-making time to allow or disallow certain policy-specifiedbehaviors, and centralized configuration management for the securityengines.

The systems and procedures discussed herein enable the security of acomputing system to be centrally managed by targeting security policiesto a particular computing system or a group of computing systems.Additionally, these systems and procedures collect and correlate eventsand other information, such as security-related events, generated bythose computing systems or other data sources.

In one embodiment, the interface supports client access to securitypolicies and event databases via secure, authenticated protocols. Theinterface permits the communication between various components orapplication programs and one or more security engines. The interfacealso defines how the security engines communicate with each other andwith other devices, components, services, or programs.

In one embodiment, the interface is defined as a COM interface, using acustom loader to reduce the likelihood of an attacker switching securityengines for the attacker's own code by changing the COM registry values.

In an example embodiment, the function calls supported by the API are:

Agent-to-Security Engine Function Calls

-   -   Initialize    -   Shutdown    -   PreparePolicy    -   CommitPolicy    -   RollbackPolicy    -   WriteData    -   WriteConfig        These seven function calls are referred to as the        “ISecurityEngine interface”.

Security Engine-to-Agent Function Calls

-   -   ReadAndRegisterNotifyData    -   WriteSEData    -   UnRegisterNotifyData    -   GetDataAttribute    -   ReadAndRegisterNotifyConfig    -   UnRegisterNotifyConfig    -   QueryUser    -   Complete        The first seven function calls above are referred to as the        “ISecurityAgent interface” and the last function call (Complete)        is referred to as the “IAgentCallback interface”.

A function call may also be referred to as a “call”, “method”,“function”, or “service”. Details regarding these function calls areprovided below. Alternate embodiments may use additional function callsand/or may omit one or more of the function calls discussed herein.

In one embodiment, an agent, such as an event manager or a securityagent communicates with the security engines via the API. An agent mayalso be referred to as a “manager”. In particular embodiments, the agentwill not call a particular security engine when an API call is alreadyoutstanding. There are exceptions to this rule for the asynchronous APIcalls. In these cases, the permitted agent actions are defined below instate tables.

Initialize Function Call

This method is called once for each security engine that is known to theagent. The method is called during agent startup. The Initializefunction call loads the security engine and allows it to performinitialization operations.

This method is called asynchronously in turn for each security engine bythe agent, and the callbacks are processed as they are received. Theagent will wait for all the callbacks to complete before continuing.

This method is defined as follows:

HRESULT Initialize( [in] ISecurityAgent *pAgent, [in] IAgentCallback*pCallback);

pAgent is a COM interface that can be used by the security engines tocall back into the agent.

pCallback is the callback object defined below.

If the Initialize function call fails, or if it does not return in areasonable amount of time, then Shutdown will be called. Due to possiblerace conditions, security engines handle Shutdown before Initialize hasreturned.

Shutdown Function Call

This method is called once for each security engine that was called toInitialize by the agent. The method allows the security engine to beginits shutdown processing. Even if Initialize failed, the agent callsShutdown to allow the security engine to close any resources that wereallocated. For example, this method allows the security engine toperform a complex shutdown that cannot be performed duringDLL_PROCESS_DETACH handling.

Since this method may take a significant amount of time to complete, ituses a callback object to indicate that it has completed shutdownprocessing. When this method is called as a result of in-process systemshutdown, the time available for processing to complete is limited, andthe agent may be terminated by the system before the callback iscompleted.

This method is defined as follows:

typedef enum tagSHUTDOWN_TYPE {   SHUTDOWN_NORMAL = 0,   SHUTDOWN_SYSTEM} SHUTDOWN_TYPE; HRESULT Shutdown( [in] SHUTDOWN_TYPE eType,     [in]IAgentCallback *pCallback );

eType is an enumeration of either SHUTDOWN_NORMAL or SHUTDOWN_SYSTEM.

pCallback is the callback object defined below.

DLL Unload will occur after the Shutdown callback has been made (or thetimeout has occurred). Since the callback can be made asynchronously,the agent may have to wait for the thread that made the callback to exitbefore continuing to unload the security engine DLL. This allows thecallback stack frame to unwind to a point outside the DLL that will beunloaded and avoid an exception in the process. If the callback is madeduring the Shutdown call, this extra step is not necessary, because thesecurity engine threads are assumed to be shutdown.

Errors are logged as operational events but otherwise ignored, becausethe Agent is about to close down anyway.

PreparePolicy Function Call

This method is called by the agent when it receives an updated policy.The resulting policies are merged and each RuleSet is built to pass tothe correct security engine. The XML data is passed as an IStream objectthat can be used by MSXML (Microsoft XML)—either DOM (Document ObjectModel) or SAX (Simple API for XML)—to read the XML data. This method isdefined as follows:

HRESULT PreparePolicy( [in] IStream *pstreamRuleset,   [in]IAgentCallback *pCallback);

pstreamRuleset is a COM interface to a Stream object that allows readingof the XML Rule Set. This IStream can be assumed to be local to themachine and not accessing data across the network.

pCallback is the callback object defined below.

If the call returns an error, the security engine is assumed to becontinuing to run the previously-applied policy (which may be aboot-time policy). The agent calls a RollbackPolicy for all securityengines whose PreparePolicy succeeds, but not for any failing securityengine. This process is started as soon as any security engine returnsan error. In addition, if the PreparePolicy callback does not arrive ina timely manner, the agent treats this as a failure on the part of thatsecurity engine. Therefore, security engines assume that the agent cancall RollbackPolicy before the PreparePolicy call has returned.

CommitPolicy Function Call

This method is called by the agent when all the security engines havereturned success on PreparePolicy calls. This call causes them to switchto the new policy. This method is defined as follows:HRESULT CommitPolicy(void);

This call is synchronous, and the agent will wait for one call tocomplete before moving on to the next call. In one embodiment, it isexpected that all the work that could fail a policy update is performedin the PreparePolicy call and this call is a simple switch from the oldto the new policy data structures.

The CommitPolicy method returns catastrophic failures, such as a failureof communications between User and Kernel parts of the security engine.When this call does return an error, the agent attempts to reload theprevious policy and re-apply that policy. Since there was an error, thismay not work and the policy enforcement will be left in an unknownstate. An operational error will be logged by the agent if CommitPolicyfails.

RollbackPolicy Function Call

This method is called by the agent when a security engine returns anerror on its PreparePolicy call. This call causes the agent to call allthe other security engines to abort the update and revert to thein-force policy. This method is defined as follows:HRESULT RollbackPolicy(void);

This call is asynchronous because the rollback processing expected ofthe security engines is extensive, roughly mirroring that in handlingPreparePolicy. When the security engine is done processing this call,the security engine calls Complete to indicate the status of therollback.

If policy is rolled back, any data registered following PreparePolicy isderegistered by the agent—the system is rolled back to the previous setof data subscribed by each security engine. For this reason, thesecurity engines do not discard their local copies of orphaned datauntil they receive the CommitPolicy call from the agent. The agent isresponsible for handling the timing window where ReadAndRegisterDatacalls from security engines arrive during policy rollback.

RollbackPolicy and the Complete callback may return catastrophicfailures. It is expected that security engines implement PreparePolicysuch that rollback can be supported. An operational error is logged bythe agent when RollbackPolicy fails. No assumption can be made about thestate of policy enforcement by that security engine and any cooperatingsecurity engines after this happens. Future policy updates will continueto be sent to the security engine.

WriteData Function Call

This method is called by the agent when a piece of data that thesecurity engine has previously called ReadAndRegisterNotifyData forchanges. The parameters are similar to the ReadAndRegisterNotifyDatacall, except that the memory ownership belongs with the agent, so thesecurity engine must not delete the item once it is processed.

WriteData is not called when the security engine is in the process ofreceiving a new policy from the agent; i.e., between calls toPreparePolicy and CommitPolicy/RollbackPolicy. Any data changes detectedby the agent at this time are batched up and sent down to the interestedsecurity engines once the new policy has been committed or rolled back.The queue of pending updates is optimized by the agent to avoid as faras possible communicating multiple consecutive changes to the same pieceof data. The WriteData method is defined as follows:

#define DF_DYNAMIC 0x1 #define DF_COLLECTION 0x2 #define DF_BOOLEAN 0x4#define DF_PERSISTED 0x8 HRESULT WriteData(   [in] REFGUID guidDataID,  [in] DWORD dwFlags,   [in] DWORD dwDataSize,   [in] VARIANT varData,  [in] DWORD dwKeySize,   [in] byte *pbKeyValue);

The parameters for passing a Key (dwKeySize, pbKeyValue) are used whenpassing context associated with a previous query back to the securityengine. The security engine uses this context to correlate the result ofthe query with a previous QueryUser call that it issued to the agent.This extra data is necessary because a given query may occur multiplyfor different contexts in the same rule—for example, asking the userwhether application X is allowed to modify a registry value, then laterasking the same question about application Y.

Errors are logged as Operational Events but otherwise ignored. Futureupdates to the same piece of data will still be notified to the failingsecurity engine. If the security engine wishes to prevent this, it cancall UnRegisterNotifyData for that piece of data.

WriteConfig Function Call

This method allows the agent to distribute configuration data tointerested security engines. Once a security engine has read theconfiguration data using the ReadAndRegisterNotifyConfig method, it willbe informed of changes to that data by the agent calling this method.The method is defined as follows:

HRESULT WriteConfig(   [in] WCHAR *wszDataName,   [in] VARIANT varData);

wszDataName is the Text name of the configuration data item beingwritten, and is the name used in the registry for this data.

varData is the variant structure that contains the single data item thatthe name represents. This data can be of various types, depending onwhat the type of the data is in the registry. The agent does no typechecking—the security engine is expected to check the data type as itrequires, according to the context.

Errors are logged as Operational Events but otherwise ignored. Futureupdates to the same configuration parameter data will still be notifiedto the failing security engine. If the security engine wishes to preventthis, it should call UnRegisterNotifyConfig for that piece of data.

A particular security engine does not typically call the agent while anAPI call from that agent is already outstanding. The agent treats thisas an error and ignores the second call.

ReadAndRegisterNotifyData Function Call

This method allows a security engine to read data from the dynamic rulesdata subsystem for use in their rules processing. Once a security enginehas read the data, it will be informed of changes to that data by theagent calling the WriteData method of the ISecurityEngine interface. Themethod is defined as follows:

HRESULT ReadAndRegisterNotifyData(   [in] REFGUID guidDataID,     [out]DWORD *pdwFlags,   [out] DWORD *pdwDataSize,   [out] VARIANT *pvarData);

guidDataID is the GUID of the data item to retrieve.

pdwFlags is a set of flags that describe the data item. Example valuescan be DYNAMIC or STATIC as well as COLLECTION or BOOLEAN.

pdwDataSize is the total size of the Data Items in the array that isreturned in the variant data.

pvarData is the variant structure that contains a reference to the arrayof data items, or the data item value for Boolean data types. Thevariant is empty on input.

It is an error for a security engine to ask for data that is no longerin the policy. The agent will generate an Operational Event on anyerror. In this case, there is no guarantee that the security engine andthe agent have a consistent view of the affected data.

WriteSEData Function Call

This method is called by the security engine when a piece of datachanges that the security engine owns and publishes (for persistence, oruse by other security engines. The parameters are similar to theWriteData call, except that the memory ownership belongs with thesecurity engine, so the agent does not delete the item once it isprocessed. The method is defined as follows:

HRESULT WriteSEData(   [in] REFGUID guidDataID,   [in] DWORD dwDataSize,  [in] VARIANT varData);

This method can be called at any time, including while anotherWriteSEData call is still outstanding, on any thread. It is the agent'sresponsibility to ensure serialization, if necessary.

The owner of a data item is identified in the collection definition by aGUID that defines the owner. This could be the GUID of a security engineor an identifier for the agent, or possibly an identifier for anotherconsumer.

If a security engine defines a collection that it owns, it is assumedthat the data will be published to the agent via this API.

The agent will log any error as an Operational Event. The securityengine can decide whether or not to continue providing updates after anerror. There is no guarantee that the agent's version of the data isconsistent with the security engine's view after an error.

UnRegisterNotifyData Function Call

This method allows a security engine to stop receiving WriteDatanotifications for data items it is no longer interested in. The methodis defined as follows:

HRESULT UnRegisterNotifyData(   [in] REFGUID guidDataID);

guidDataID is the GUID identifying the data item for which the securityengine is no longer interested in change notifications. The securityengine can indicate that it wishes to deregister all currentnotifications by passing in the Null GUID{00000000-0000-0000-000000000000}.

The agent will log any error as an Operational Event. This includes thecase where the data is not known to the agent, to assist with diagnosisof policy management problems.

GetDataAttribute Function Call

This method allows a security engine to retrieve a particular attributeassociated with a data item. The attribute name is the same as the namethat is in the Policy XML, including the case of the text. Attributevalues can only change when a policy is changed, so there is nonotification system needed for this data. The method is defined asfollows:

HRESULT GetDataAttribute(   [in] REFGUID guidDataID,     [in] WCHAR*wszAttributeName, [out] VARIANT *pvarAttributeValue);

This method can be called at any time.

guidDataID is the GUID identifying the data item to retrieve theattribute for.

wszAttributeName is the name of the attribute, exactly as it is in thepolicy document.

pvarAttributeValue is the attribute value as a Variant. Normal outputparameter allocation rules apply. The agent allocates a new Variant withthe information and it is the caller's responsibility to free it later.

ReadAndRegisterNotifyConfig Function Call

This method allows a security engine to read configuration data from theagent. Once a security engine has read the configuration data, it willbe informed of changes to that data by the agent calling the WriteConfigmethod of the ISecurityEngine interface.

Configuration data for the agent and its hosted security engines may belocated under a common root. The method is defined as follows:

HRESULT ReadAndRegisterNotifyConfig(   [in] WCHAR *wszDataName,   [out]VARIANT *pvarData);

wszDataName is the Text name of the configuration data item to retrieve,and is the name used in the registry for this data. This identifies theindividual item relative to the common agent root. No leading ‘\’character is required. The value is case-insensitive, but whitespacecharacters are significant.

pvarData is the variant structure that contains the single data itemthat the name represents. This data can be of various types, dependingon what the type of the data is in the registry. The agent does no typechecking—the security engine is expected to check the data type as itrequires, according to the context.

The agent will log any error as an Operational Event.

UnRegisterNotifyConfig Function Call

This method allows a security engine to stop receiving WriteConfignotifications for data items it is no longer interested in. The methodis defined as follows:

HRESULT UnRegisterNotifyConfig(   [in] WCHAR *wszDataName);

wszDataName is the Text name identifying the configuration data item forwhich the security engine is no longer interested in changenotifications.

The agent will log any error as an Operational Event. This includes thecase where the data is not known to the agent, to assist with diagnosisof configuration management problems.

QueryUser Function Call

This method allows a security engine to ask the agent to display aspecific message to the user, returning the answer that the userselected. The agent can also cache this answer, and persist that valueover agent re-starts. The question that the user is presented with cancontain specific information about why the user is being asked thisquestion. This information can be provided by the security engine andcan be different each time this method is called. How the agent decideswhether this question has been asked before and what the answer is, isdetermined by the Key Information that the security engine provides.

The call returns to the security engine immediately. The security enginethen suspends the operation of the session/thread that triggered thisquery until it is notified of a response. This happens when the userkeys in a response, or when the Query times out. The timeout processingis handled by the agent. At this point, the agent updates the relevantdata-item with the keyed or default response, and notifies the securityengine of the result with its associated context.

Since obtaining a response to such queries is time-critical, this APIcan be called at any time by a security engine that is enforcing a rulerequiring a query to be issued. The method is defined as follows:

HRESULT QueryUser(   [in] REFGUID guidQueryItem,   [in] DWORD dwKeySize,[in] byte *pbKeyValue, [in] SAFEARRAY(VARIANT) pvarQueryParams);

guidQueryItem is the GUID of the data item that contains the basestrings that are used to ask the user the question, and provide thepossible answers to that question.

dwKeySize is the length of the Key Value, in bytes.

pbKeyValue is the set of bytes that define the unique key for thisquery.

pvarQueryParams is a Safearray of Variants containing the queryparameters to be substituted into the query text that is displayed tothe user. The order and syntax of the parameters is defined by the ruletype with which this QueryUser action is associated.

The agent will return an error if the data item is not identifiable.Errors in executing the query will be logged as Operational Events. Inthis case, the default action is returned to the security engine.

Complete Function Call

This method notifies the agent that a security engine has completedprocessing associated with a prior asynchronous call from the agent tothat security engine. Although a particular security engine canpotentially have more than one asynchronous calls from the agentoutstanding, the agent manages internal state for each security enginesuch that the context of a particular Complete callback is unambiguous.The method is defined as follows:

HRESULT Complete(   [in] HRESULT hrCompletionCode);

hrCompletionCode is the return code for the asynchronous call the agentpreviously made to this security engine.

Interface Usage

The following describes example restrictions on how these APIs are usedto interact with one or more security engines.

At a particular time, the security engine is in a certain state withrespect to its interactions with the agent. The following listidentifies possible security engine states.

State Definition Pending_Initialize The security engine DLL has beenloaded but no API calls received yet. The Policy state at this pointdepends on the security engine - NSE has a boot- time policy, behavioralblocking has none until it is given rules by the agent. InitializingInitialize has been called but not completed Running The security enginehas called back the agent to say it Initialized successfully, and isenforcing either (initially) boot-time or (after subsequentCommitPolicy) agent-supplied policy Preparing_Policy PreparePolicy hasbeen called but no callback has happened Policy_Prepared PreparePolicycallback completed with success return code, waiting for CommitPolicycall Policy_Rollback Security engine called with RollbackPolicy,processing the rollback request Shutting_Down Shutdown has been calledbut not completed Pending_Termination Shutdown complete - waiting forprocess termination

The permitted interactions between the agent and security engines can beformalized as a set of tables which define the APIs that can be calledby each entity when a security engine is in a particular state, and whatstate change or other action needs to be taken by the security engine asa result. The operational state of the agent is assumed to beunimportant—the security engines can assume it remains in normaloperation at all times while the security engines are loaded intomemory.

The state tables cover the following phases of the security engine'slifecycle:

-   -   Initialization    -   Policy Update from agent    -   Shutdown

Any combination of API call and security engine state not covered inthese tables can be considered a misuse of the API. It is theresponsibility of the API caller to avoid such misuse.

The following state table defines the permitted sequences of APIs duringsecurity engine initialization, and security engine state changesaccording to inputs from the agent. A call to any API not listed as apermitted input for the list of states associated with security engineinitialization implies a protocol error on the calling entity's part.

Pending_Initialize Initializing Security Engine State Agent API CallsInitialize Initializing ERROR Shutdown ERROR Pending_TerminationWriteConfig ERROR OK Security Engine API Calls Complete(OK) ERRORRunning (no policy) Complete(FAIL) ERROR Pending_TerminationReadAndRegisterNotify ERROR OK Config

The following state table defines the permitted sequences of APIs duringpolicy update, and the associated security engine state changes. A callto any API not listed as a permitted input here for the list of statesassociated with policy update implies a protocol error on the callingentity's part.

Security Engine State Agent API Calls Running Preparing_PolicyPreparePolicy Preparing_(—) ERROR Policy WriteConfig OK OK SecurityEngine API Calls Complete(OK) ERROR Policy_Prepared Complete(FAIL) ERRORRunning (old policy) ReadAndRegisterNotifyConfig OK OKReadAndRegisterNotifyData OK OK

Policy_Prepared Security Engine State Agent API Calls CommitPolicyRunning (new policy) RollbackPolicy Policy_Rollback (old policy)WriteConfig OK Security Engine API Calls Complete(OK) ERRORComplete(FAIL) ERROR ReadAndRegisterConfig OK ReadAndRegisterData OK

An example of the overall policy update sequence, taking into accountmultiple hosted security engines, is described below.

1. Each security engine's PreparePolicy is called.

2. The agent waits for each security engine to call Complete withSuccess or a Failure.

3. If any security engine reports a failure, every other security enginewill have their RollbackPolicy method called.

4. If no security engine reports a failure, the CommitPolicy method iscalled for each security engine.

5. If another failure is discovered, or if a Shutdown is necessary,before any CommitPolicy methods are called, the RollbackPolicy method iscalled for each security engine.

The following state table defines the permitted sequences of APIs duringsecurity engine shutdown, and security engine state changes according toinputs from the agent. A call to any API not listed as a permitted inputhere for the list of states associated with security engine shutdownimplies a protocol error on the calling entity's part.

Initializing, Running, Preparing_Policy, Policy_Prepared,Policy_Rollback Shutting_Down SE State Agent API Calls ShutdownShutting_Down ERROR SE API Calls Complete ERROR Pending_Termination

Listed below are example collection types supported by the agent, anddescriptions regarding how each collection is passed as dynamic datathrough the ReadAndRegisterNotifyData and WriteData method calls.

Many of the data items discussed below can be handled by passing asingle BSTR string, or packing unsigned integers into a LONG or aLONGLONG variant type. Those items that don't easily fit this model are:DirectorySet, ProtocolSet and IPv4AddressSet. For each of these types apacking system is suggested that packs the data into a BSTR string toallow easy transfer in a SafeArray.

FileSet

Data passed for each item:

-   -   Filename—string

Implementation:

-   -   BSTR

DirectorySet

Data passed for each item:

-   -   Directory Name—String    -   Recursive—Flag

Implementation:

-   -   Packed BSTR—“Recursive Flag:String”

Recursive Flag is a single character—

-   -   ‘R’—Recursive    -   ‘F’—Flat

RegistrySet

Data passed for each item:

-   -   Registry Key Name—String

Implementation:

-   -   Packed BSTR—“Recursive Flag:String”

Recursive Flag is a single character—

-   -   ‘R’—Recursive    -   ‘F’—Flat

Protocol

Data passed for each item:

-   -   Primary/Secondary—String or Enumeration    -   IP Type—String or Enumeration    -   Direction—String or Enumeration    -   Port or Port Range—One or Two Integers (16 bit, unsigned        integers)

Implementation:

-   -   Packed LONGLONG:        -   1 Byte—Primary/Secondary        -   1 Byte—IP Type TCP/UDP        -   1 Byte—Direction In/Out/Both        -   1 Byte—Unused        -   2 Bytes—Port Range End (or Zero)        -   2 Bytes—Port Range Start (or Port)

ProcessSet

Data passed for each item:

-   -   Process Name or Path—String

Implementation:

BSTR

NetworkPortSet

Data passed for each item:

-   -   Port or Port Range—One or Two Integers (16 bit, unsigned        integers)

Implementation:

-   -   Packed LONG: Start=Low Word, End=High Word. High Word is Zero if        not a Port Range

NetworkIPv4AddressSet

Data passed for each item:

-   -   One of:        -   IPv4 Address—String (can contain wildcards)        -   IPv4 Address Range—2 Strings        -   FQDN—String        -   Hostname—String

Implementation:

-   -   Packed BSTR: “T:String 1:String 2”        -   T—Type—One Character for Address, Address Range, HostName or            FQDN        -   String 1—Address, Start Address, HostName or FQDN        -   String 2—End Address for Address Range

UserSet

Data passed for each item:

-   -   User Account Name—String

Implementation:

-   -   BSTR

UserGroupSet

Data passed for each item:

-   -   User Group Name—String

Implementation:

-   -   BSTR

FileOpSet

Data passed for each item:

-   -   File Operation—String (or Enumeration)

Implementation:

-   -   BSTR

DirOpSet

Data passed for each item:

-   -   Directory Operation—String (or Enumeration)

Implementation:

-   -   BSTR

ProcessOpSet

Data passed for each item:

-   -   Process Operation—String (or Enumeration)

Implementation:

-   -   BSTR

RegKeyOpSet

Data passed for each item:

-   -   Registry Key Operation—String (or Enumeration)

Implementation:

-   -   BSTR

RegValueOpSet

Data passed for each item:

-   -   Registry Value Operation—String (or Enumeration)

Implementation:

-   -   BSTR

UserOpSet

Data passed for each item:

-   -   User Account Operation—String (or Enumeration)

Implementation:

-   -   BSTR

UserGroupOpSet

Data passed for each item:

-   -   User Group Operation—String (or Enumeration)

Implementation:

-   -   BSTR

JobOpSet

Data passed for each item:

-   -   Job Operation—String (or Enumeration)

Implementation:

-   -   BSTR

Generic

Data passed for each item:

-   -   Value—String

Implementation:

-   -   BSTR

QuerySet

To the security engine, QuerySet appears as a single item collectionthat contains the result of a query to the user. The associated contextis passed to the security engine as a separate parameter. The internalstructure of the QuerySet is not typically needed by a security engine,only the context and the query result.

Boolean (boolDefine)

Data passed for the single item:

-   -   Boolean—True or False

Implementation:

-   -   LONG—False=0, True=1

FIG. 9 illustrates a general computer environment 900, which can be usedto implement the techniques described herein. The computer environment900 is only one example of a computing environment and is not intendedto suggest any limitation as to the scope of use or functionality of thecomputer and network architectures. Neither should the computerenvironment 900 be interpreted as having any dependency or requirementrelating to any one or combination of components illustrated in theexample computer environment 900.

Computer environment 900 includes a general-purpose computing device inthe form of a computer 902. One or more media player applications can beexecuted by computer 902. The components of computer 902 can include,but are not limited to, one or more processors or processing units 904(optionally including a cryptographic processor or co-processor), asystem memory 906, and a system bus 908 that couples various systemcomponents including the processor 904 to the system memory 906.

The system bus 908 represents one or more of any of several types of busstructures, including a memory bus or memory controller, apoint-to-point connection, a switching fabric, a peripheral bus, anaccelerated graphics port, and a processor or local bus using any of avariety of bus architectures. By way of example, such architectures caninclude an Industry Standard Architecture (ISA) bus, a Micro ChannelArchitecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video ElectronicsStandards Association (VESA) local bus, and a Peripheral ComponentInterconnects (PCI) bus also known as a Mezzanine bus.

Computer 902 typically includes a variety of computer readable media.Such media can be any available media that is accessible by computer 902and includes both volatile and non-volatile media, removable andnon-removable media.

The system memory 906 includes computer readable media in the form ofvolatile memory, such as random access memory (RAM) 910, and/ornon-volatile memory, such as read only memory (ROM) 912. A basicinput/output system (BIOS) 914, containing the basic routines that helpto transfer information between elements within computer 902, such asduring start-up, is stored in ROM 912. RAM 910 typically contains dataand/or program modules that are immediately accessible to and/orpresently operated on by the processing unit 904.

Computer 902 may also include other removable/non-removable,volatile/non-volatile computer storage media. By way of example, FIG. 9illustrates a hard disk drive 916 for reading from and writing to anon-removable, non-volatile magnetic media (not shown), a magnetic diskdrive 918 for reading from and writing to a removable, non-volatilemagnetic disk 920 (e.g., a “floppy disk”), and an optical disk drive 922for reading from and/or writing to a removable, non-volatile opticaldisk 924 such as a CD-ROM, DVD-ROM, or other optical media. The harddisk drive 916, magnetic disk drive 918, and optical disk drive 922 areeach connected to the system bus 908 by one or more data mediainterfaces 925. Alternatively, the hard disk drive 916, magnetic diskdrive 918, and optical disk drive 922 can be connected to the system bus908 by one or more interfaces (not shown).

The disk drives and their associated computer-readable media providenon-volatile storage of computer readable instructions, data structures,program modules, and other data for computer 902. Although the exampleillustrates a hard disk 916, a removable magnetic disk 920, and aremovable optical disk 924, it is to be appreciated that other types ofcomputer readable media which can store data that is accessible by acomputer, such as magnetic cassettes or other magnetic storage devices,flash memory cards, CD-ROM, digital versatile disks (DVD) or otheroptical storage, random access memories (RAM), read only memories (ROM),electrically erasable programmable read-only memory (EEPROM), and thelike, can also be utilized to implement the example computing system andenvironment.

Any number of program modules can be stored on the hard disk 916,magnetic disk 920, optical disk 924, ROM 912, and/or RAM 910, includingby way of example, an operating system 926, one or more applicationprograms 928, other program modules 930, and program data 932. Each ofsuch operating system 926, one or more application programs 928, otherprogram modules 930, and program data 932 (or some combination thereof)may implement all or part of the resident components that support thedistributed file system.

A user can enter commands and information into computer 902 via inputdevices such as a keyboard 934 and a pointing device 936 (e.g., a“mouse”). Other input devices 938 (not shown specifically) may include amicrophone, joystick, game pad, satellite dish, serial port, scanner,and/or the like. These and other input devices are connected to theprocessing unit 904 via input/output interfaces 940 that are coupled tothe system bus 908, but may be connected by other interface and busstructures, such as a parallel port, game port, or a universal serialbus (USB).

A monitor 942 or other type of display device can also be connected tothe system bus 908 via an interface, such as a video adapter 944. Inaddition to the monitor 942, other output peripheral devices can includecomponents such as speakers (not shown) and a printer 946 which can beconnected to computer 902 via the input/output interfaces 940.

Computer 902 can operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computingdevice 948. By way of example, the remote computing device 948 can be apersonal computer, portable computer, a server, a router, a networkcomputer, a peer device or other common network node, game console, andthe like. The remote computing device 948 is illustrated as a portablecomputer that can include many or all of the elements and featuresdescribed herein relative to computer 902.

Logical connections between computer 902 and the remote computer 948 aredepicted as a local area network (LAN) 950 and a general wide areanetwork (WAN) 952. Such networking environments are commonplace inoffices, enterprise-wide computer networks, intranets, and the Internet.

When implemented in a LAN networking environment, the computer 902 isconnected to a local network 950 via a network interface or adapter 954.When implemented in a WAN networking environment, the computer 902typically includes a modem 956 or other means for establishingcommunications over the wide network 952. The modem 956, which can beinternal or external to computer 902, can be connected to the system bus908 via the input/output interfaces 940 or other appropriate mechanisms.It is to be appreciated that the illustrated network connections areexemplary and that other means of establishing communication link(s)between the computers 902 and 948 can be employed.

In a networked environment, such as that illustrated with computingenvironment 900, program modules depicted relative to the computer 902,or portions thereof, may be stored in a remote memory storage device. Byway of example, remote application programs 958 reside on a memorydevice of remote computer 948. For purposes of illustration, applicationprograms and other executable program components such as the operatingsystem are illustrated herein as discrete blocks, although it isrecognized that such programs and components reside at various times indifferent storage components of the computing device 902, and areexecuted by the data processor(s) of the computer.

Various modules and techniques may be described herein in the generalcontext of computer-executable instructions, such as program modules,executed by one or more computers or other devices. Generally, programmodules include routines, programs, objects, components, datastructures, etc. that perform particular tasks or implement particularabstract data types. Typically, the functionality of the program modulesmay be combined or distributed as desired in various embodiments.

An implementation of these modules and techniques may be stored on ortransmitted across some form of computer readable media. Computerreadable media can be any available media that can be accessed by acomputer. By way of example, and not limitation, computer readable mediamay comprise “computer storage media” and “communications media.”

“Computer storage media” includes volatile and non-volatile, removableand non-removable media implemented in any method or technology forstorage of information such as computer readable instructions, datastructures, program modules, or other data. Computer storage mediaincludes, but is not limited to, RAM, ROM, EEPROM, flash memory or othermemory technology, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can be accessed by acomputer.

“Communication media” typically embodies computer readable instructions,data structures, program modules, or other data in a modulated datasignal, such as carrier wave or other transport mechanism. Communicationmedia also includes any information delivery media. The term “modulateddata signal” means a signal that has one or more of its characteristicsset or changed in such a manner as to encode information in the signal.By way of example, and not limitation, communication media includeswired media such as a wired network or direct-wired connection, andwireless media such as acoustic, RF, infrared, and other wireless media.Combinations of any of the above are also included within the scope ofcomputer readable media.

Notionally, a programming interface may be viewed generically, as shownin FIG. 10 or FIG. 11. FIG. 10 illustrates an interface Interface1 as aconduit through which first and second code segments communicate. FIG.11 illustrates an interface as comprising interface objects I1 and I2(which may or may not be part of the first and second code segments),which enable first and second code segments of a system to communicatevia medium M. In the view of FIG. 11, one may consider interface objectsI1 and I2 as separate interfaces of the same system and one may alsoconsider that objects I1 and I2 plus medium M comprise the interface.Although FIGS. 10 and 11 show bi-directional flow and interfaces on eachside of the flow, certain implementations may only have information flowin one direction (or no information flow as described below) or may onlyhave an interface object on one side. By way of example, and notlimitation, terms such as application programming or program interface(API), entry point, method, function, subroutine, remote procedure call,and component object model (COM) interface, are encompassed within thedefinition of programming interface.

Aspects of such a programming interface may include the method wherebythe first code segment transmits information (where “information” isused in its broadest sense and includes data, commands, requests, etc.)to the second code segment; the method whereby the second code segmentreceives the information; and the structure, sequence, syntax,organization, schema, timing and content of the information. In thisregard, the underlying transport medium itself may be unimportant to theoperation of the interface, whether the medium be wired or wireless, ora combination of both, as long as the information is transported in themanner defined by the interface. In certain situations, information maynot be passed in one or both directions in the conventional sense, asthe information transfer may be either via another mechanism (e.g.,information placed in a buffer, file, etc. separate from informationflow between the code segments) or non-existent, as when one codesegment simply accesses functionality performed by a second codesegment. Any or all of these aspects may be important in a givensituation, e.g., depending on whether the code segments are part of asystem in a loosely coupled or tightly coupled configuration, and sothis list should be considered illustrative and non-limiting.

This notion of a programming interface is known to those skilled in theart and is clear from the foregoing detailed description of theinvention. There are, however, other ways to implement a programminginterface, and, unless expressly excluded, these too are intended to beencompassed by the claims set forth at the end of this specification.Such other ways may appear to be more sophisticated or complex than thesimplistic view of FIGS. 10 and 11, but they nonetheless perform asimilar function to accomplish the same overall result. We will nowbriefly describe some illustrative alternative implementations of aprogramming interface.

Factoring

A communication from one code segment to another may be accomplishedindirectly by breaking the communication into multiple discretecommunications. This is depicted schematically in FIGS. 12 and 13. Asshown, some interfaces can be described in terms of divisible sets offunctionality. Thus, the interface functionality of FIGS. 10 and 11 maybe factored to achieve the same result, just as one may mathematicallyprovide 24, or 2 times 2 times 3 times 2. Accordingly, as illustrated inFIG. 12, the function provided by interface Interface1 may be subdividedto convert the communications of the interface into multiple interfacesInterface1A, Interface 1B, Interface 1C, etc. while achieving the sameresult. As illustrated in FIG. 13, the function provided by interface I1may be subdivided into multiple interfaces I1 a, I1 b, I1 c, etc. whileachieving the same result. Similarly, interface I2 of the second codesegment which receives information from the first code segment may befactored into multiple interfaces I2 a, I2 b, I2 c, etc. When factoring,the number of interfaces included with the 1^(st) code segment need notmatch the number of interfaces included with the 2^(nd) code segment. Ineither of the cases of FIGS. 12 and 13, the functional spirit ofinterfaces Interface1 and I1 remain the same as with FIGS. 10 and 11,respectively. The factoring of interfaces may also follow associative,commutative, and other mathematical properties such that the factoringmay be difficult to recognize. For instance, ordering of operations maybe unimportant, and consequently, a function carried out by an interfacemay be carried out well in advance of reaching the interface, by anotherpiece of code or interface, or performed by a separate component of thesystem. Moreover, one of ordinary skill in the programming arts canappreciate that there are a variety of ways of making different functioncalls that achieve the same result.

Redefinition

In some cases, it may be possible to ignore, add or redefine certainaspects (e.g., parameters) of a programming interface while stillaccomplishing the intended result. This is illustrated in FIGS. 14 and15. For example, assume interface Interface1 of FIG. 10 includes afunction call Square(input, precision, output), a call that includesthree parameters, input, precision and output, and which is issued fromthe 1^(st) Code Segment to the 2^(nd) Code Segment. If the middleparameter precision is of no concern in a given scenario, as shown inFIG. 14, it could just as well be ignored or even replaced with ameaningless (in this situation) parameter. One may also add anadditional parameter of no concern. In either event, the functionalityof square can be achieved, so long as output is returned after input issquared by the second code segment. Precision may very well be ameaningful parameter to some downstream or other portion of thecomputing system; however, once it is recognized that precision is notnecessary for the narrow purpose of calculating the square, it may bereplaced or ignored. For example, instead of passing a valid precisionvalue, a meaningless value such as a birth date could be passed withoutadversely affecting the result. Similarly, as shown in FIG. 15,interface I1 is replaced by interface I1′, redefined to ignore or addparameters to the interface. Interface I2 may similarly be redefined asinterface I2′, redefined to ignore unnecessary parameters, or parametersthat may be processed elsewhere. The point here is that in some cases aprogramming interface may include aspects, such as parameters, that arenot needed for some purpose, and so they may be ignored or redefined, orprocessed elsewhere for other purposes.

Inline Coding

It may also be feasible to merge some or all of the functionality of twoseparate code modules such that the “interface” between them changesform. For example, the functionality of FIGS. 10 and 11 may be convertedto the functionality of FIGS. 16 and 17, respectively. In FIG. 16, theprevious 1^(st) and 2^(nd) Code Segments of FIG. 10 are merged into amodule containing both of them. In this case, the code segments maystill be communicating with each other but the interface may be adaptedto a form which is more suitable to the single module. Thus, forexample, formal Call and Return statements may no longer be necessary,but similar processing or response(s) pursuant to interface Interface1may still be in effect. Similarly, shown in FIG. 17, part (or all) ofinterface I2 from FIG. 11 may be written inline into interface I1 toform interface I1″. As illustrated, interface I2 is divided into I2 aand I2 b, and interface portion I2 a has been coded in-line withinterface I1 to form interface I1″. For a concrete example, considerthat the interface I1 from FIG. 11 performs a function call square(input, output), which is received by interface I2, which afterprocessing the value passed with input (to square it) by the second codesegment, passes back the squared result with output. In such a case, theprocessing performed by the second code segment (squaring input) can beperformed by the first code segment without a call to the interface.

Divorce

A communication from one code segment to another may be accomplishedindirectly by breaking the communication into multiple discretecommunications. This is depicted schematically in FIGS. 18 and 19. Asshown in FIG. 18, one or more piece(s) of middleware (DivorceInterface(s), since they divorce functionality and/or interfacefunctions from the original interface) are provided to convert thecommunications on the first interface, Interface1, to conform them to adifferent interface, in this case interfaces Interface2A, Interface2Band Interface2C. This might be done, e.g., where there is an installedbase of applications designed to communicate with, say, an operatingsystem in accordance with an Interface1 protocol, but then the operatingsystem is changed to use a different interface, in this case interfacesInterface2A, Interface2B and Interface2C. The point is that the originalinterface used by the 2^(nd) Code Segment is changed such that it is nolonger compatible with the interface used by the 1^(st) Code Segment,and so an intermediary is used to make the old and new interfacescompatible. Similarly, as shown in FIG. 19, a third code segment can beintroduced with divorce interface DI1 to receive the communications frominterface I1 and with divorce interface DI2 to transmit the interfacefunctionality to, for example, interfaces I2 a and I2 b, redesigned towork with DI2, but to provide the same functional result. Similarly, DI1and DI2 may work together to translate the functionality of interfacesI1 and I2 of FIG. 11 to a new operating system, while providing the sameor similar functional result.

Rewriting

Yet another possible variant is to dynamically rewrite the code toreplace the interface functionality with something else but whichachieves the same overall result. For example, there may be a system inwhich a code segment presented in an intermediate language (e.g.Microsoft IL, Java ByteCode, etc.) is provided to a Just-in-Time (JIT)compiler or interpreter in an execution environment (such as thatprovided by the Net framework, the Java runtime environment, or othersimilar runtime type environments). The JIT compiler may be written soas to dynamically convert the communications from the 1^(st) CodeSegment to the 2^(nd) Code Segment, i.e., to conform them to a differentinterface as may be required by the 2^(nd) Code Segment (either theoriginal or a different 2^(nd) Code Segment). This is depicted in FIGS.20 and 21. As can be seen in FIG. 20, this approach is similar to theDivorce scenario described above. It might be done, e.g., where aninstalled base of applications are designed to communicate with anoperating system in accordance with an Interface 1 protocol, but thenthe operating system is changed to use a different interface. The JITCompiler could be used to conform the communications on the fly from theinstalled-base applications to the new interface of the operatingsystem. As depicted in FIG. 21, this approach of dynamically rewritingthe interface(s) may be applied to dynamically factor, or otherwisealter the interface(s) as well.

It is also noted that the above-described scenarios for achieving thesame or similar result as an interface via alternative embodiments mayalso be combined in various ways, serially and/or in parallel, or withother intervening code. Thus, the alternative embodiments presentedabove are not mutually exclusive and may be mixed, matched and combinedto produce the same or equivalent scenarios to the generic scenariospresented in FIGS. 10 and 11. It is also noted that, as with mostprogramming constructs, there are other similar ways of achieving thesame or similar functionality of an interface which may not be describedherein, but nonetheless are represented by the spirit and scope of theinvention, i.e., it is noted that it is at least partly thefunctionality represented by, and the advantageous results enabled by,an interface that underlie the value of an interface.

Although the description above uses language that is specific tostructural features and/or methodological acts, it is to be understoodthat the invention defined in the appended claims is not limited to thespecific features or acts described. Rather, the specific features andacts are disclosed as exemplary forms of implementing the invention.

1. A programming interface embodied on one or more computer storagemedia, comprising: instructions to communicate a new security policy toa plurality of security engines, wherein at least one of the pluralityof security engines implements an antivirus service, wherein each of theplurality of security engines is configured to replace an existingsecurity policy with the new security policy, and wherein a new set ofrules and/or data associated with the new policy is provided to eachsecurity engine; and instructions to communicate an indication of eachsecurity engine's readiness to implement the new security policy,wherein each of the plurality of security engines returns a valuesignifying whether it has processed the new set of rules and/or datareceived to indicate readiness to implement the new security policy. 2.A programming interface as recited in claim 1 wherein the instructionsto communicate a new security policy to a plurality of security enginesinclude a method that instructs each of the plurality of securityengines to delete the new security policy.
 3. A programming interface asrecited in claim 1 wherein the instructions to communicate a newsecurity policy to a plurality of security engines include a method thatinitializes a particular security engine.
 4. A programming interface asrecited in claim 1 wherein the instructions to communicate a newsecurity policy to a plurality of security engines include a method thatinstructs each of the plurality of security engines to implement the newsecurity policy.
 5. A programming interface as recited in claim 1wherein the instructions to communicate a new security policy to aplurality of security engines further comprise a method thatcommunicates new data associated with an existing security policy to atleast one of the plurality of security engines.
 6. A programminginterface as recited in claim 1 wherein the instructions to communicatea new security policy to a plurality of security engines furthercomprise a method that communicates configuration information to atleast one of the plurality of security engines.
 7. A programminginterface as recited in claim 1 wherein the instructions to communicatean indication of each security engine's readiness to implement the newsecurity policy include a method that indicates whether a particularsecurity engine has implemented the new security policy.
 8. Aprogramming interface as recited in claim 1 wherein the instructions tocommunicate an indication of each security engine's readiness toimplement the new security policy further comprise a method thatretrieves updated data associated with a particular security policy. 9.A programming interface as recited in claim 1 wherein the instructionsto communicate an indication of each security engine's readiness toimplement the new security policy further comprise a method thatcommunicates new data identified by one of the plurality of securityengines to a security agent.
 10. A programming interface as recited inclaim 1 wherein the instructions to communicate an indication of eachsecurity engine's readiness to implement the new security policy furthercomprise a method that allows one of the plurality of security enginesto query a user of a system containing the plurality of securityengines.
 11. A programming interface as recited in claim 1 wherein atleast one of the plurality of security engines implements a firewallapplication.
 12. A programming interface as recited in claim 1 whereinthe plurality of security engines implement the new security policyafter all security engines have indicated a readiness to implement thenew security policy.
 13. A computer system including: one or moremicroprocessors; and one or more software programs, the one or moresoftware programs utilizing an application program interface toimplement a security policy on a plurality of security engines, whereinat least one of the plurality of security engines implements anantivirus service, the application program interface comprising thefollowing functions: a first function that communicates a new securitypolicy to the plurality of security engines, wherein a new set of rulesand/or data associated with the new policy is communicated; a secondfunction that identifies whether each of the plurality of securityengines is prepared to apply the new security policy based on a valuegenerated by each of the plurality of security engines signifyingwhether it has processed the new set of rules and/or data; and a thirdfunction that instructs each of the plurality of security engines toimplement the new security policy after determining that all of thesecurity engines are prepared to apply the new security policy.
 14. Acomputer system as recited in claim 13 further comprising a fourthfunction that causes each of the plurality of security engines to deletethe new security policy if at least one of the plurality of securityengines is unable to apply the new security policy.
 15. A computersystem as recited in claim 13 further comprising a fourth functionrelated to communicating event information identified by a firstsecurity engine to the other security engines.
 16. A computer system asrecited in claim 13 further comprising a fourth function related tocommunicating security-related information identified by a firstsecurity engine to an event manager.
 17. A computer system as recited inclaim 16 wherein the event manager communicates the security-relatedinformation to at least one of the plurality of security engines.
 18. Acomputer system as recited in claim 13 wherein at least one of theplurality of security engines is associated with a first type ofsecurity attack.
 19. A computer system as recited in claim 18 wherein atleast one of the plurality of security engines is associated with asecond type of security attack.
 20. A method comprising: calling atleast one of a plurality of first functions to facilitate communicatinga security policy to a first security engine, wherein at least one ofthe plurality of security engines implements an antivirus service;calling at least one of a plurality of second functions to facilitatedetermining whether the first security engine has applied the securitypolicy; and calling at least one of a plurality of third functions tofacilitate communicating security-related information from the firstsecurity engine to a second security engine, wherein the first securityengine communicates whether it is ready to apply the security policy.21. A method as recited in claim 20 wherein the security-relatedinformation identifies a type of security attack.
 22. A method asrecited in claim 20 further comprising calling one or more fourthfunctions to facilitate interacting with a user of a system containingthe first security engine.
 23. A method as recited in claim 20 furthercomprising calling one or more fourth functions to facilitatecommunicating configuration information to the first security engine.24. A method as recited in claim 20 further comprising calling one ormore fourth functions to facilitate instructing the first securityengine and the second security engine to implement the security policy.25. A method as recited in claim 20 further comprising calling one ormore fourth functions to facilitate communicating a revised securitypolicy to the first security engine.
 26. A system comprising: means forstoring instructions facilitating an application program interfaceimplementing a security policy on a plurality of security engines; meansfor defining a first function that communicates a security-related eventto an event manager, wherein the security-related event is detection ofa virus, and wherein the communication of the security-related eventincludes information or details of the event being communicated; meansfor defining a second function that identifies a plurality of securityengines associated with the security-related event, wherein theidentified security engines are those security engines determined to beable to use the event information; and means for defining a thirdfunction that communicates the security-related event from the eventmanager to the identified security engines thus each of the plurality ofsecurity engines need not know of the other security engines; means fordefining a fourth function that communicates a new security policy fromthe event manager to the plurality of security engines to increasesecurity based on shared event information; means for defining a fifthfunction that instructs the plurality of security engines to replace anexisting security policy with the new security policy; and means fordefining a sixth function that communicates the ability of the pluralityof security engines to replace an existing security policy with the newsecurity policy.
 27. A system as recited in claim 26 further comprising:means for defining a seventh function that instructs the plurality ofsecurity engines to implement the new security policy if all of theplurality of security engines can implement the new security policy. 28.A system as recited in claim 27 further comprising means for defining afunction that instructs the plurality to security engines to delete thenew security policy if at least one of the plurality of security enginescannot implement the new security policy.
 29. A system as recited inclaim 26 comprising means for detecting the security related eventwherein the security-related event further comprises an unauthorizedattempt to access a storage device.
 30. A system as recited in claim 26further comprising means for defining a function that notifies the eventmanager that a particular security engine has finished processinganother function call.